1. Field of the Invention
This invention generally relates to Web pages, and more specifically, the invention relates to providing or adding sections of content to Web pages. Even more specifically, the preferred embodiment of the invention relates to systems and methods for serving multiple data objects and formatting functions in a single request.
2. Background Art
The use of a client side scripting language library, such as a JavaScript library, that provides dynamically generated content is a relatively new approach to embedding one or more sections of content on a web page. This approach has many advantages. Because it requires no server-to-server integration between the server hosting the web page and the server hosting the JavaScript library, a web page developer simply embeds a URL to one or more JavaScript libraries (possibly along with a few line of JavaScript code) and the dynamic content provided by the JavaScript library is added to the page. This significantly reduces the complexities required to integrate third party content into a web page. Because there is no server-to-server integration, there is no need to worry about software compatibility between the server generating the web page and the server providing the third-party content. Also, there is no need for the web page developer to work with a server-side API to integrate the embedded content into the web page. This is because the integration occurs when the page is rendered by the browser, not when the client-side markup language, such as HTML, is being generated on the web server.
Typically, the dynamically generated JavaScript library provides a function to embed its content onto the web page. Optionally, CSS (or similar technology) is used to adjust the “look and feel” of the content to more closely match that of the including page. A disadvantage of this approach is that if the formatting of the content provided by the JavaScript library does not provide the formatting desired for the including page, then a new JavaScript library must be created to provide content with the desired format. This additional JavaScript library uses the same or similar set of data as the first JavaScript library, but provides this data in a different content format. As more variations of these dynamically generated JavaScript libraries are created for various content formats, updates across all variations can become difficult to maintain. Also, each additional dynamically generated JavaScript library must interface with whatever back-end system is providing the data.
An improvement to this approach is to have the JavaScript library generate the data component of the content without specifying the content formatting. Then, any number of independent formatting functions can be created. Each of these formatting functions can take the same type of data object as a parameter, but use this data to output content in very different formats. This approach provides a much greater degree of flexibility. For each new content format that is needed, there is no longer a need to create multiple variations of the data object. Formatting functions can now be provided by any server, completely independent from the server providing the data object. No integration or awareness is needed between the server providing the data object and the server providing the formatting function. The only requirement is that the formatting function be written in a way that is compatible with the data object that it receives as a parameter.
A key disadvantage of the above-discussed approaches is that when a page needs to embed many different sections of dynamically generated content, this page must submit a separate request to obtain each data object and formatting function needed on the page. This can result in several requests to the server(s) hosting the data objects and formatting functions. This need to send multiple requests impacts the response time of the page containing the multiple sections of embedded content.
Another disadvantage is that the URI to each data object and formatting function must be specified by every page wishing to include this content. If the URI of a data object or formatting function needs to change, every page using this URI must be updated when the change occurs, or the embedded section of content will no longer work on this page.
One example of a section of content that may be added to Web pages is work embedded learning, which can be defined as learning content (or links to learning content, or connections to experts that can provide learning) that is provided within the context of performing a specific task. Key characteristics of work embedded learning are that the learning content changes based on page context (i.e., the primary information or task on a web page) and, possibly, based on attributes of the user accessing this page (i.e., different content may be provided for users in a different job role, geographic location, organization, etc.). Work embedded learning offers significant business value through enhanced employee performance.
Two of the past approaches to providing work embedded learning (and other sections of content on a page) have been:                1. Manually adding supporting content to each page; and        2. Integrating the supporting content with the primary page content via a web application server or other server-side program.        
The problem with the first approach is that updates to the content or functionality of supporting content require manual changes to each page. This quickly becomes a time-consuming, error-prone process if this approach is used for more than a few hundred pages. Also, custom content based on user attributes is not possible with this approach.
The second approach resolves the data management issues introduced by the first approach, however, it too has fundamental limitations. The system providing the work embedded learning (A) must run on the same server as the application generating the primary content, or (B) must be accessed by the primary application server via an API over the network (i.e., a SOAP interface, CORBA, COM, etc.).
A key disadvantage of limitation (A) is that the supporting content application code must be deployed onto every application server wishing to use this supporting content. This introduces additional resource and performance demands on this application server. Also, it requires that the supporting content application code be compatible with the application server in question. If the supporting content application code runs on a different application platform (i.e., .NET vs. J2EE vs. Domino) or if it requires a different version of the same platform, the primary application platform must be upgraded (or downgraded), or the supporting content application simply cannot be used. None of these alternatives is desirable.
While approach (B) does not require compatible application server platforms, it does require that an API be available on the primary platform for communicating to the supporting content application server over the network. If a compatible API is not available, one must be developed. Also, approach (B) requires a network connection to pass data from the supporting content application server to the primary application server. This introduces a potentially significant performance hit and/or additional complexity and resource demands (such as an advanced caching strategy), especially for personalized, context sensitive, or language-specific supporting content.
Approaches (A) and (B) also typically have a development and testing cost associated with integrating the primary page content with the supporting content API. Also, it is important to note that neither approach (A) nor (B) is capable of embedding supporting content into static HTML pages, or into dynamic pages running on an application server that does not have a compatible API for communicating with the supporting content application.